Low Earth Orbit (LEO) satellite networks is a promising approach for global data communications (including broadband) in view of their low delay and bit error characteristics compared to Geostationary (GEO) satellites. Moreover, LEO satellites do not require high power antennas on ground terminals due to their close distance to the ground. However, because of the orbit, the communication link between a ground terminal and an LEO satellite will be available periodically for only a few minutes at a time. In order to provide continuous communication between ground terminals, the LEO satellites need to be interconnected via inter-satellite links (called crosslinks) and terminal-terminal data traffic will be routed over multiple satellites using these crosslinks. Typically, an LEO satellite network consists of multiple orbit planes, and each plane consists of multiple satellites. The satellite topology (neighbor relationship) within a plane remains invariant while inter-plane topology will change constantly; interplane crosslinks will be dynamically set up and removed. Terminal-satellite associations (uplink and downlink connectivity) will also be changing constantly. Traffic routing in such a dynamically changing network considering the Quality of Service (QoS) requirements of user traffic, network failures, and network congestion is a complex problem. Unlike network equipment in terrestrial networks, the size, weight, and power (SWaP) requirements of network equipment in satellites are very limited and stringent. Despite this constraint, the communication payload in an LEO satellite needs to provide a networking service that is robust, provides the required QoS, and adapts to changes in network conditions.
A prior solution described in V. V. Gounder, R. Prakash, H. Abu-Amara, Routing in LEO-Based Satellite Networks, IEEE Symposium on Wireless Communications and Systems, April 1999 proposes a virtual connection-oriented approach based on tag switching to route data in a LEO satellite network. Routing tables are computed by ground stations and uploaded to satellites at predetermined intervals. Routes are computed in ground stations for different network snapshots. Only forwarding tables for a limited set of snapshots are uploaded to LEO satellites. The payload switch does not have any route adaptation capabilities. All rerouting computations and decisions are made only by ground stations.
This networking solution described does not allow automatic adaptation by satellite payloads to network failure and congestion conditions. The network operations center on the ground receives such conditions, recomputes changes in network routes, and uploads new forwarding tables to the payloads. This solution has the following drawbacks: responses to network problems and anomalies take more time since all responses involve processing in the ground center and communication between the ground center and the satellites and there is lack of satellite autonomy. If the ground center-satellite network connectivity fails, no adaptation in data forwarding is possible by the payloads.
Another prior solution described in V. Mancuso, G. Bianchi, N. B. Melazzi, U. Bimbacher, Switched Ethernet Networking Over LEO Satellite, Proc. of IEEE IWSSC '05, September 2005 proposes an Ethernet Virtual LAN switching based networking solution for LEO satellites. Each possible path across the LEO network between a pair of ground terminals is viewed as a distinct VLAN. A network operations center on the ground determines all VLANs and uploads VLAN membership information to all payloads. Source terminals on the ground tag Ethernet frames with VLAN IDs, switching from one tag to another when their satellite connectivity changes. Switches in payloads build a spanning tree for each VLAN using standard spanning tree protocols.
This described solution requires payloads to incorporate spanning tree protocols thereby requiring more processing and storage capabilities in payloads. Furthermore, this solution does not address network adaptation to failures and congestion conditions.
A further prior solution described in U.S. Pat. No. 6,404,769, issued Jun. 11, 2002, inventor Vijay Kapoor, entitled “Directional Routing of Packets in a Satellite Network”, proposes a method for routing packets across a satellite constellation that comprises multiple orbital planes, each plane carrying multiple satellites that are equally spaced in the plane. Satellites in the same orbital plane are connected via north-south crosslinks. Satellites in different orbital planes are connected via east-west crosslinks. When a connection is needed between two satellites that are in different planes, a controller station on the ground determines a route for the connection taking into account the traffic load on various crosslinks. The route so determined consists of a “band” which denotes a logical region in the constellation that is orthogonal to orbital planes. The controller provides this route information including the band information, the destination plane, and the destination satellite id to the source satellite which includes it in all packets belonging to that connection. Satellites forward packets using this route information by forwarding packets on the source plane until the specified band is reached, then on the band towards the destination plane, and finally on the destination plane towards the destination satellite. In this method, the satellites do not have any route adaptation capabilities. All routing decisions are made only by the controller on the ground.
This routing solution assumes that the satellite network topology is fixed. In comparison, the adaptive forwarding concept described in the present invention does not have this limitation and is applicable to satellite networks with dynamically changing topologies. In addition, the forwarding method described in the present invention is independent of the routing scheme used in the ground controller. For example, the present invention can support the routing solution just described as well as other routing schemes that consider dynamically varying satellite network topologies. The present invention does not include any specific routing method.
Several proposals have been made in the literature for distributed routing in LEO satellite networks; i.e., each payload router determines routing decisions independently for each packet. A specific solution described in E. Ekici, I. F. Akyildiz, M. D. Bender, A Distributed Routing Algorithm for Datagram Traffic in LEO Satellite Networks, IEEE/ACM Transactions on Networking, Vol. 9, No. 2, April 2001 proposes a distributed routing algorithm that is capable of avoiding congested network regions and is also capable of rerouting packets around failure points with low degradation in performance.
A still further prior solution described in T. R. Henderson, R. H. Katz, On Distributed, Geographic-Based packet Routing for LEO Satellite Networks, Proc. of IEEE Globecom 2000, December 2000 proposes a distributed routing algorithm that utilizes geographic information encoded in the address fields in packet headers and computes satellite routes minimizing the geographic distance of routes.
Unlike these solutions, the present invention does not employ distributed routing by payloads to minimize SWaP requirements. Payloads perform only switching based on routes computed by network operations centers on the ground.